Does this introduce another change in behavior when working with clip space in shaders like reverse-z did, like e.g. reconstructing position from depth? Or does the math work out such that shaders are unchanged? I don't see any GLSL in the changed files.

Stumbled upon a few other places in Projection that need the fix on z plane calculation (other than Projection::get_projection_planes()).

Some of those functions are not used anywhere in the code but could still be called in user modules or custom builds :

• Projection::get_projection_plane()
• Projection::get_z_far()
• Projection::get_far_plane_half_extents()

I just updated the PR.

Notes from the rendering weekly meeting :

is it fine to “detect” infinite matrices from their values right into Projection, instead of passing through a flag set by Camera3D based on far value ? (I’ve seen a “is_orthogonal” flag passed through whereas orthogonality could have been likewise detected from the matrix components themselves)

Yes, detecting infinite far is fine, but the fact that the projection uses an infinite far should propagate to further steps in rendering (i.e. the construction of the projection matrix + projection for screen space effects)

any further test project needed to bullet proof the fix ? (thinking of light culling, fog rendering, gi, and other stuff that uses far plane extraction)

Extensive testing will be needed. I don't think we have test coverage over this yet. So probably need to write code tests as well as a graphical demo for comparison

any other changes you may have in mind to fully unlock infinite far planes ? (thinking of 1 minor improvement : remove far distance capping in editor - but there might be more)

This is a good start, but the support would need to reach through the rendering pipeline to anything that is touched by the far plane. We rely on the far distance in many places in the renderer, all of these need to be checked

I am sorry, I can not help with tests on this one after all. Too much work and life issues now.